Role based access control (RBAC) systems are gaining popularity as the methodology for choice for managing network privileges, access to network resources, and other security policies. RBAC systems assign roles to users or classes of users. Each role is defined by a class of occupants, and by actions that the class of occupants is allowed to perform in accessing and utilizing some or all of the resources on a network. Thus, in a RBAC system, the privileges (including network privileges, permissions to access protected resources, and privileges to perform actions) and authorizations of a particular user will depend on the role or roles that the user occupies.
For example, one user on a network may have only one role that corresponds to “employee”. The role of “employee” provides the user with a certain set of privileges, including use of basic network resources, or the ability to perform certain employee functions. Another user may have two roles that correspond to “employee” and “manager”. As a “manager”, the second user may have access to network resources that are not available to the user that is only an “employee”. Similarly, an “employee” who also has the role of an “administrator” may have the most privileges of anyone who can use the network.
Generally, RBAC systems are classified within four broad classes. RBAC0 systems are basic RBAC systems in which roles comprise a set of occupants and permissions. RBAC1 systems support hierarchies of roles; for example, the role Employee may include sub-roles Manager and Engineer. RBAC2 systems enforce principles of mutual exclusion or separation of duties. RBAC2 systems may provide for static mutual exclusion or dynamic mutual exclusion. RBAC3 systems combine the features of RBAC1 and RBAC2 systems.
One core concept that can be implemented through RBAC systems is separation of duties (SoD). The concept of SoD provides a security mechanism that protects a system of networked elements, including applications hosted by the networked elements, from the action of one user that is acting within that user's authorizations. For example, SoD may be used to limit the damage that one network user can cause through bad intent, negligence or oversight. To implement SoD, certain roles on the network are defined as mutually exclusive of other roles. SoD policies specify that users may not occupy roles that are mutually exclusive. A static SoD policy specifies that a user can never occupy two or more individual roles that are designated as “statically” mutually exclusive. A dynamic SoD policy specifies that a user can occupy two or more individual roles that are “dynamically” mutually exclusive, but the “dynamically” mutually exclusive roles cannot be occupied at the same time.
In past approaches, static and dynamic SoD policies are themselves defined statically. Thus, an administrator configures each role with either static SoD or dynamic SoD, and the specification does not change as an application runs. For example, an administrator may designate a set of roles that are statically mutually exclusive from one another, and another set of roles that are dynamically mutually exclusive from one another. For example, in a hypothetical business purchasing management application with SoD, given a “purchaser” role and a “purchase approver” role, one scenario provides that the administrator designates the two roles as statically exclusive, meaning that a user designated as being a “purchaser” can never be designated as a “purchase approver”. Another scenario provides that the administrator designates the two roles as being dynamically exclusive, meaning that the user can occupy both “purchaser” and “purchase approver” roles, but never at the same time.
This type of static definition for roles can become inconvenient in certain business environments. In particular, the role assignments may be too inflexible for various situations presented in a given business environment. For example, in the “purchaser” and “purchase approver” example provided above, there is no simple mechanism for enabling a user to approve his own purchase of a few dollars. The additional approval required in the static scenario, or the additional time required for the user to switch roles in the dynamic scenario, are burdensome when considering the context that what is being requested is purchase approval authority of a few dollars. A business cannot readily delegate this authority on a case-by-case basis. Specifically, a business cannot automate delegation of this authority on a case-by-case basis.
The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.